With the increasing availability of broadband Internet access and the increasing number of consumer devices provided with IP connectivity, the distribution of digital content (such as music and movies) has been moving from using physical content carriers like CDs, DVDs and Blu-ray discs to online distribution. Typically, in online content acquisition and distribution, a consumer purchases digital content online from a retailer. After purchasing content, the consumer can download the content from a download service provider (DSP) associated with the retailer. A device used by a consumer to access content acquired from the retailer is referred to as a client terminal in this document (a client terminal is also referred to as customer premises equipment in the literature). A personal computer, a mobile device and a pay-TV set-top box are examples of a client terminal.
A digital rights management (DRM) system can be used to control access to digital content and to enforce content usage rules. In a DRM system, content is encrypted before it is distributed to a consumer (that is, to a client terminal of the consumer) to control access to the content. If a consumer purchases content, then the DSP generates a DRM licence for that content and distributes the DRM licence to the client terminal of the consumer. The DRM licence contains a content key required to decrypt (or access) the content and a set of usage rules associated with the content. The DRM licence and the encrypted content are input to a DRM client at the client terminal. The DRM client verifies the usage rules contained in the DRM licence. If these usage rules are satisfied, then the DRM client provides access to the content, enabling the client terminal to render the content. A number of different types of DRM systems exist, each with their own content packaging method, content encryption method, DRM licence format and content usage rules.
DRM systems typically support the concept of DRM domains. A DRM domain consists of one or more DRM clients, and is associated with the client terminals that contain a DRM client of the DRM domain. A domain of client terminals associated with a DRM domain will also be referred to as a domain of client terminals in the following. For example, a domain of client terminals may comprise a number of client terminals owned by a particular consumer. After content is purchased from the retailer, the associated DSP generates a DRM licence for the content and the DRM domain. Next, the DSP distributes the content and the DRM licence to one of the client terminals in the DRM domain. The DRM licence enables all client terminals in the DRM domain to access the content. In other words, the consumer can copy the content and the DRM licence from one client terminal to another client terminal in the domain of client terminals, allowing the other client terminal to access (or render) the content without acquiring a new DRM licence (and without needing an online connection between the moment of copying the content and the DRM licence and the moment of rendering the content using the other client terminal). DRM systems typically support dynamic DRM domains in that a DRM client (and its associated client terminal) can join or leave a DRM domain. For example, a consumer may be allowed to select the client terminals in the domain of client terminals, as long as their total number does not exceed a pre-defined maximum number of client terminals. In general, a DRM client (and its associated client terminal) may be associated with more than one DRM domain.
Prior art DRM systems typically allow any DSP to service the DRM client at a client terminal (under the assumption that the DSP has an agreement with the associated DRM supplier). In other words, prior art DRM systems typically allow any DSP to manage the DRM domain or DRM domains associated with the DRM client (the DRM domains being defined independently by every DSP), to generate DRM licences, and to distribute content and DRM licences to the client terminal.
Before distributing content, the content is first packaged in a file format supported by the DRM system. Next, the packaged content is encrypted using an encryption method supported by the DRM system. FIG. 1 shows an example of a prior art DSP 10, including a content packaging module 12 and a content encryption module 14. In practice, the content may already be packaged and encrypted when it is delivered to the DSP, e.g., the content provider may have performed these operations.
The DSP 10 of FIG. 1 manages DRM clients using a DRM key management module 16. The DRM key management module generates key management messages. A key management message is used to distribute cryptographic keys (other than the key used to encrypt content which is distributed using a DRM licence, as detailed later) to the client terminal 20 which includes a DRM client 22. For example, a key management message can be used to allow the client terminal to join a DRM domain, as discussed later.
DRM licences are created by a DRM licence management module 18 at the DSP 10. A DRM licence allows a client terminal 20 to access the content associated with the DRM licence. The DRM licence is associated with either a particular DRM client, or with a particular DRM domain. As a DRM domain may consist of a single DRM client, the DRM key management and DRM licence management associated with a particular DRM client is similar to the DRM key management and DRM licence management associated with a particular DRM domain comprising one DRM client. For ease of exposition, the examples described in this document therefore assume without loss of generality that a DRM licence is associated with a DRM domain.
In the following, Ei(K,M) denotes the encryption of a message M using encryption method Ei and the encryption key K. The encryption method Ei is defined by an encryption algorithm and a mode of operation for the encryption algorithm. The encryption methods Ei of the schemes described in this document generally use a symmetric encryption algorithm. A symmetric encryption algorithm has the property that it is easy to derive the decryption key from the encryption key and the other way around. Without loss of generality, it is assumed that the encryption key is equal to the decryption key in all encryption methods Ei considered in this document. For example, the well known Advanced Encryption Standard (AES) with a block size of 128 bits and a key size of 128 bits can be used as the encryption algorithm for all encryption methods Ei considered in this document. Please refer to the NIST document “Specification for the advanced encryption standard (AES), Federal Information Processing Standards Publication 197, 2001” in this respect.
In practice, the electronic codebook (ECB) mode of operation is often used to encrypt and decrypt keys. The mode of operation used for encrypting and decrypting content depends on the type of DRM system; two popular modes for encrypting and decrypting content are the cipher-block chaining mode and the counter mode. Throughout this document, Di(K,C) denotes the decryption of a ciphertext C using decryption method Di and the key K, with the property that Di(K, Ei(K,M))=M for all messages M and for all keys K (and for all values of i considered in this document).
However, asymmetric encryption algorithms (also referred to as public key encryption schemes in the literature) can be used as well as or instead of symmetric schemes, if desired, by making suitable adjustments to the described embodiments where necessary in ways which will be familiar to the skilled person.
Content (e.g., a movie) protected by a DRM system is generally encrypted using a content key CK. To encrypt content, the DSP 10 may first generate a content key CK (e.g., an AES key). The DSP 10 encrypts the content using content encryption function E1 and CK to produce the encrypted content E1(CK, Content). The DSP 10 stores the encrypted content in a database containing all content that can be distributed to a client terminal 20. In addition, the DSP 10 securely stores the content key CK.
If a client terminal 20 joins a DRM domain, then a DRM client key DCK may be distributed to the DRM client associated with or embedded in the client terminal, using a key management message generated by the DRM key management module 16. It is assumed here that DCK is a symmetric key, but instead a DCK can be the private key of an asymmetric key pair if a public key encryption scheme is used. This DCK is a shared key in that all client terminals in the DRM domain require access to this key to process DRM licences associated with the DRM domain. If the client terminal 20 is the first client terminal joining the DRM domain, then the DRM key management module 20 may first generate a DCK (e.g., using a pseudo-random number generator). Before distributing the DCK to a client terminal 20, the DRM key management module 16 typically protects the confidentiality and the authenticity of DCK using one or more higher-level DRM keys. For example, the DRM key management module 16 may encrypt DCK using a higher-level DRM key, and generate a message authentication code or a digital signature using another higher-level DRM key. The message authentication code or digital signature can be appended to the encrypted DCK, producing an initialisation message DCKinit. In general, DCKinit may be any message from which the DRM client associated with client terminal 20 is able to derive the key DCK. The DRM key management module 16 includes DCKinit in a key management message, and distributes this key management message to the client terminal 20.
In some cases the key DCK or the DCKinit message is pre-loaded in the DRM client (e.g., DCK or DCKinit may have been loaded in the DRM client before the DRM client was installed in the client terminal 20). If a DCK or a DCKinit message is pre-loaded in the DRM client, then no key management message containing DCKinit needs to be distributed to the client terminal 20. In addition, if a DCK is pre-loaded in the DRM client, then no corresponding DCKinit message needs to be generated.
After a consumer purchases content from a retailer, the associated DSP 10 generates a DRM licence associated with the content and DRM domain. To do this the DSP retrieves the content key CK that was used to encrypt the content and the DCK associated with the DRM domain from secure storage. The content key CK is then encrypted using the DCK and the encryption function E2, producing the ciphertext E2(DCK,CK). This ciphertext is included in the DRM licence, which is distributed to a client terminal 20 associated with the DRM domain. The DRM licence may also include content usage rules.
Because the DSP has stored the content key CK, the DSP 10 can generate DRM licences containing the same content key CK for different DRM domains. Further, as the DCK associated with different DRM domains will be different, the encrypted content key will differ in these DRM licences, making a DRM licence specific for a DRM domain. In particular, if encrypted content is copied to one or more client terminals in another DRM domain (e.g., if encrypted content is shared between different DRM domains using a peer-to-peer network), then a new DRM licence can be generated for the other DRM domain and distributed to a client terminal in the other DRM domain, enabling the client terminals in the other DRM domain to render the copied content. In addition, if the DSP 10 pre-loads the encrypted content on client terminals (e.g., on client terminals associated with different DRM domains), then a DRM licence can be generated for a DRM domain and distributed to a client terminal in the DRM domain in order to enable the client terminals in the DRM domain to render the pre-loaded content. Such distribution methods are generally referred to as content super-distribution in the prior art.
FIG. 2 shows one way in which the content may be rendered at a prior art client terminal 20. The DRM client 22 first derives DCK from the initialisation message DCKinit, delivered in a key management message 31, at a derive DCK function 30. For example, the derive DCK function 30 may verify the authenticity of the initialisation message using a higher-level DRM key, and if the initialisation message is authentic, then the derive DCK function 30 may decrypt the initialisation message using a higher-level DRM key, producing DCK. Second, the encrypted content E1(CK, Content) and the DRM licence 32 are input to the DRM client. If the DRM licence contains content usage rules, then the DRM client 22 verifies these content usage rules. If the content usage rules are satisfied, then the DRM client decrypts the encrypted content key E2(DCK,CK) using decryption function D2 and DCK, producing content key CK. Third, the DRM client 22 uses content decryption function D1 and the content key CK to decrypt the encrypted content E1(CK, Content), producing the plaintext content 34, which can be rendered by the client terminal 20.
In practice, a prior art DSP 10 typically uses a DCK for generating multiple DRM licences 32 (associated with multiple pieces of content for the DRM domain). This implies that a DRM client 22 in the DRM domain uses DCK for accessing multiple pieces of encrypted content. If DCK is re-used, then the key management message 31 containing the corresponding DCKinit message does not need to be distributed with every DRM licence (recall that no key management message containing DCKinit needs to be distributed to the client terminal 20 if the key DCK or the DCKinit message was pre-loaded in the DRM client).
If a client terminal leaves a DRM domain, then the client terminal 20 may delete its stored DCKinit messages and DCKs associated with the DRM domain and the DSP (e.g., its DRM key management module 16) may generate a new DCK and distribute this new DCK to the other client terminals in the DRM domain using new DCKinit messages and new key management messages. In general, the DSP and/or the client terminal may take any action that prevents the client terminal that leaves the DRM domain from further processing DRM licences associated with the DRM domain.
The prior art DRM client 22 illustrated in FIG. 2 may be implemented in software executed on an integrated circuit in the client terminal. Alternatively, the prior art DRM client 22 may be implemented inside a detachable hardware module. Software and/or hardware protection techniques may be used to make the DRM client tamper-resistant and read-proof (e.g., to prevent an adversary from compromising secret keys or modifying content usage rules). In addition, a measure may be implemented to bind/lock the DRM client 22 to the client terminal 20. Such a measure can prevent an adversary from using the DRM client 22 to illegally render the plaintext content 34 on another client terminal (that is, to render the plaintext content 34 on a client terminal outside the DRM domain).
For performance reasons, the content decryption algorithm or method is often implemented in a hardware decryption module (also referred to as a hardware accelerator in the prior art literature). Such an implementation is shown in FIG. 3 in which the DRM client 22 outputs the content key CK. The content key CK and the encrypted content E1(CK, Content) are provided as input to a content decryption module 36. The content decryption module decrypts the encrypted content E1(CK, Content) using content decryption function D1 and the content key CK, producing the plaintext content 34, which can be rendered by the client terminal 20 or a content rendering device connected to the client terminal 20 (for instance, the client terminal may be a pay-TV set-top box connected to a television).
In the example depicted in FIG. 3, it is assumed that the content decryption module 36 is implemented in an integrated circuit of the client terminal 20. The DRM client 22 may be implemented in the same integrated circuit. Alternatively, the DRM client 22 may be implemented in a separate integrated circuit of the client terminal 20, or the DRM client 22 may be implemented in a detachable hardware module.
Software and/or hardware protection techniques may be used to make the DRM client 22 and/or the content decryption module 36 tamper-resistant and read-proof (e.g., to prevent an adversary from compromising secret keys or modifying content usage rules). Further, a measure may be implemented to secure the distribution of CK from the DRM client 22 to the content decryption module 36. For instance, the DRM client 22 may encrypt the content key CK using a higher-level key shared between the DRM client and the content decryption module 36, and pass the encrypted content key to the content decryption module (instead of passing the plaintext content key CK to the content decryption module). Next, the content decryption module 36 can decrypt the encrypted content key received from the DRM client 22 using the shared higher-level key, producing the plaintext content key CK.
In addition, a measure may be implemented to bind/lock the DRM client 22 to the client terminal 20. Such a measure can prevent an adversary from using the DRM client 22 to illegally render the plaintext content 34 on another client terminal (that is, to render the plaintext content 34 on a client terminal outside the DRM domain). For example, the DRM client 22 may encrypt CK in such a way that the resulting ciphertext can only be decrypted correctly by the content decryption module 36 of the client terminal 22 (e.g., by making the shared higher-level key used to encrypt and decrypt CK unique to that combination of DRM client and content decryption module).
The implementation of a DRM client 22 (and the implementation of the content decryption algorithm or method if a hardware accelerator is used) usually has/have to comply with a set of DRM compliance and robustness rules as defined by the DRM supplier. For example, the DRM supplier may require that a unique number is loaded into a client terminal 20 during its manufacturing (also referred to as personalization of the client terminal). The unique number is typically used to bind/lock the DRM client 22 to the client terminal 20. For example, the DRM client 22 may implement a routine to verify the value of this unique number and only provide its functionality if the value of this number is as expected.
Frequently in the prior art, a DRM client 22 can be distributed to a client terminal 20 during its operational phase (e.g., by distributing a new detachable hardware module containing the DRM client 22 to the client terminal, or by downloading a new software image containing the DRM client 22 at the client terminal). However, a client terminal 20 can only use a DRM client 22 if the client terminal satisfies the DRM compliance and robustness rules of the associated DRM supplier. For example, the DRM compliance and robustness rules may require that a client terminal is personalized for that type of DRM system during the manufacturing stage of the client terminal. In other words, a type of DRM client for which the client terminal does not satisfy the associated DRM compliance and robustness rules cannot be used on the client terminal.
In practice, a client terminal manufacturer may select a particular type of DRM system and produce client terminals that satisfy the DRM compliance and robustness rules for that type of DRM system only, and different client terminal manufacturers may thereby selected different types of DRM systems for their client terminals. As a result, a DSP may not have influence on the type of DRM system embedded in the client terminals it wants to service. This implies that the DSP may need to implement multiple DRM systems to service its population of client terminals.
The use of multiple DRM systems in a population of client terminals may have a number of drawbacks, for example:
1. the content packaging method and/or the content encryption method may be specific to the type of DRM system. This may mean that a DSP needs to store multiple copies of the encrypted content (e.g., one copy for each type of DRM system). Moreover, it may be that no content distribution is possible between devices implementing a different type of DRM client;2. DRM licences are typically DRM system specific. This implies that two client terminals implementing a different type of DRM client cannot be in the same DRM domain. For example, if a consumer owns two client terminals that include a DRM client associated with two different types of DRM systems, then two DRM licences are required to be able to render acquired content on both client terminals, instead of one DRM licence if the client terminals would have been in the same DRM domain;3. the DSP needs to have an agreement with all of the associated DRM system suppliers, and the DSP needs to implement each of these DRM systems (content packaging, content encryption, DRM key management and DRM licence management). This may increase the costs for a DSP or the associated retailer;4. the level of system security is defined by the type of DRM system that offers the lowest level of security.
Points 1-4 as listed above can be addressed if a DSP can select and implement one type of DRM system, and distribute the DRM client of that type of DRM system to each client terminal it services. This can be achieved using hardware distribution (e.g., by distributing a detachable hardware module containing the DRM client) as well as or instead of software distribution (e.g., by downloading a new software image containing the DRM client). Such a distribution mechanism can also be used to upgrade a DRM client, for example to increase the level of security or to extend the functionality of the DRM system. In addition, the distribution mechanism enables a DSP to replace the DRM system it uses with a different type of DRM system, distributing the DRM client of the new type of DRM system to each client terminal it services. For instance, this may be desirable when the other type of DRM system offers a higher level of security. A DRM scheme with these properties may be referred to as swappable DRM, and for swappable DRM systems, a method for locking/binding a DRM client to a client terminal (or to multiple client terminals associated with a DRM domain) that is supported by a number of DRM systems (also referred to as compliant DRM systems) is needed.
As an example, a challenge-response mechanism between the DRM client and the client terminal can be defined. A client terminal implements this mechanism, enabling the client terminal to receive a challenge and to generate a response to the challenge that is unique to that client terminal. A DRM client of a compliant DRM system also implements the mechanism, enabling the DRM client to bind/lock itself to the client terminal by sending a challenge to the client terminal and by only providing its functionality if the response received from the client terminal is as expected. Alternatively, for the architecture shown in FIG. 3, the locking/binding mechanism may based on an encryption of the content key CK by the DRM client using a higher-level key shared between the DRM client and the content decryption module. If the shared higher-level key is unique to that combination of the DRM client and the content decryption module, then only that content decryption module is able to derive CK correctly from the output of the DRM client. Observe that these examples require that a security measure is implemented in the DRM client to bind/lock the DRM client to the client terminal.
It would be desirable to provide DRM control of encrypted content at client terminals which has a smaller impact on the architecture of existing DRM systems, such that little effort is required for an existing DRM system to become a compliant DRM system.